scalar: set core.fsync=all for stability #567
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The core.fsync config option was introduced in b9f5d03 (core.fsync: documentation and user-friendly aggregate options, 2022-03-15), and first shipped in Git 2.36.0. This config option allows customizing which layers of Git data require fsync().
One issue is that 020406e (core.fsync: introduce granular fsync control infrastructure, 2022-03-10) changed the default behavior of fsync()ing index files (among others) such that users are starting to see issues where their .idx files are empty, halting their interactions with their repositories.
Setting core.fsync=all will use fsync() in all possible places, avoiding this issue in any data written by Git. Here, we are preferring stability over performance. This is left as an optional setting so users can override with their preferred setting, if needed. At that point, they accept the risk of not fsync()ing.
already under reviewto consider for upstream contribution.This is something that is affecting users right now, specifically when using the GVFS protocol. The precomputed prefetch packs are getting empty
.idx
files pretty frequently. This is very likely anfsync()
issue, but the frequency is still alarming.